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January 9, 2008 



/SanjayShenoy/ 



REPLY BRIEF 



Applicants submit this Reply Brief to the Board of Patent Appeals and 
Interferences in response to Examiner's Answer mailed on November 14, 2007. While 
Applicants' maintain each of the arguments submitted in Applicants' previously 
submitted Appeal Brief, Applicants make the following further arguments in light of the 
Examiner's Answer. 
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ARGUMENTS 

Rejection of claims 10-12, 14-21, and 27-29 under 35 U.S.C. 103(a) over Win in 
view of Pazandak. 

The Applicable Standard for Establishing a Prima Facie Case of 
Obviousness. 

The Examiner bears tine initial burden of establisliing a prima facie case of 
obviousness. See MPEP § 2142. To establish a prima facie case of obviousness three 
basic criteria must be met. First, there must be some suggestion or motivation, either in 
the references themselves or in the knowledge generally available to one ordinary sl<ill 
in the art, to modify the reference or to combine the reference teachings. Second, there 
must be a reasonable expectation of success. Third, the prior art reference (or 
references when combined) must teach or suggest all the claim limitations. See MPEP 
§2143. 

Further, the Federal Circuit has held that even if all of the elements of a claimed 
invention are found in a combination of prior art references, analysis requires 
"consideration of two factors: 

(1) whether the prior art would have suggested to those of ordinary skill in the art 
that they should make the claimed composition or device, or carry out the 
claimed process; and 

(2) whether the prior art would also have revealed that in so making or carrying 
out, those of ordinary skill would have a reasonable expectation of success." 
PharmaStem Therapeutics, Inc. v. ViaCell, Inc., 491 F.3d 1342 (Fed. Cir. 
2007) 

In this regard the Federal Circuit points out that in KSR International Co. vs. 
Teleflex, Inc., 127 S. Ct. 1727 (2007) the Supreme Court "acknowledged the importance 
of identifying 'a reason that would have prompted a person of ordinary skill in the 
relevant field to combine the elements in the way the claimed new invention does' in an 
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obviousness determination." Takeda Chemical Industries, Ltd. v. Alphaphram Pty, Ltd., 
492 F.3d 1350, 1356 (Fed. Cir. 2007). 

In this case, the references, alone or in combination, fail to teach at least the first 
and third limitations. 



The Combination of Win and Pazandak Does Not Disclose All the Claim 
Elements. 

Applicants respectfully submit that Win does not disclose assigning metadata 
requirements to functional modules, wherein the assigned metadata requirements 
specify conditions required for successful execution of the functional module, as 
claimed in claims 10, 20, and the dependents therefrom. Examiner suggests that the 
'roles' as described in Win are analogous to the metadata requirements of functional 
modules. Examiner further suggests that the 'resources' as described in Win are 
analogous to functional modules, as claimed. However, the roles in Win are not 
metadata requirements that specify conditions required for successful execution of the 
functional modules. Rather, roles simply define a relationship of a user to the 
organization and determine what resources the user can access. Win describes roles 
as follows: 

"The system 2 enables administrators to implement access rules by 
defining Roles that Users play when working for an organization or doing 
business with an enterprise. A Role mav reflect a relationship of a User to 
the organization (employee, customer, distributor, supplier), their 
department within an organization (sales, marketing, engineering) or anv 
other affiliation or function (member of quality task force, hotline staff 
member) that defines their information needs and thus their access rights 
or privileges. Thus, examples of Roles include Employee, Customer, 
Distributor, Supplier, Sales, Marketing, Engineering, and Hotline Staff. 

Roles are defined by information identifying a name of a role and by 
a functional group in which the role resides. A functional group is often a 
department in which similar functions exist. Examples of functional groups 
are Marketing, Sales, Engineering, Human Resources, and Operations. 

In some embodiments, the term User Type or Person Type refers 
to employees, directors, officers, contractors, customers, distributors, etc., 
and Role refers to a job function such as sales representative, financial 
analyst, etc. 
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Roles determine what resources a User can access. Further, each role 
may require a unique set of information that is available in resources. For 
example, a User who is an Employee in the Marketing department could 
access Price List and New Products Resources. Thus, system 2 enables 
the creation of resource profiles by assigning roles to resources, and user 
profiles by assigning roles to users to generate access rights . System 2 
automatically links a user profile to the resources profiles that have been 
assigned the same roles, so that deployment of new resources may occur 
rapidly." See Win, Column 5: Lines 12-54. 

Therefore, the purpose of roles in Win is to determine access rights of a user to 

resources of a system. However, the roles do not specify any conditions for the 

successful execution of the resources. Yet, Examiner states that: 

"Win describe[s] the successful execution of resources (i.e. 
functional modules) as "a personalized menu is an HTML page containing 
a list of authorized Resources. In one embodiment, a Personalized Menu 
is an HTML page containing a list of authorized Resources. The 
Personalized Menu displays only Resources to which the User has 
access. The User can then select and access a Resource" (Column 6, 
lines 13-17), "If the name and password are correct, the Authentication 
Client Module reads the user's roles from the Registry server" (Column 6, 
lines 44-46), and "By these actions, the user specifies that persons having 
the role of "Sales Manager" are authorized to view or use the "National 
Sales Report" resource; Any user who is assigned the role of "Sales 
Manager" in the future will automatically have access to the "National 
Sales Report" resource. If the administrator later un-assigns "Sales 
Manager" from the "National Sales Report" resource, then all users 
associated with the "Sales Manager" role will automatically lose access to 
the resource" (Column 18, lines 28-36)." See page 16 of Examiner's 
Answer. 

However, Examiner's citations only reaffirm that roles simply determine which 
particular system resources are accessible by a user. Examiner's citations do not 
provide any indication that the roles specify conditions for the successful execution of 
resources. For example, even if the administrator unassigns "Sales Manager" from the 
"National Sales Report" (assuming "National Sales Report" can be construed as a 
functional module), the "National Sales Report" module may still be executed 
successfully by a user having a role other than "Sales Manager". Accordingly, the 
"Sales Manager" role does not specify conditions for the successful execution of the 
"National Sales Report." Rather, it simply determines whether a user has access to the 
"National Sales Report." 
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Examiner states that Paragraph 44 of the Application suggests that a plug-in will 
only be called by authorized users based on metadata (i.e. security requirements). 
Applicants agree that the some plug-ins may only be available to authorized users 
determined by session information 172 available in the runtime metadata 170 . 
However, as stated in Paragraph 44, "in order for a plug-in to be successfully called, or 
executed, its requirements described by associated metadata 160 needs to be met by 
parameters available to the calling application." Further, as stated in Paragraph 42, 
"associated metadata may include plug-in information such as functional concept or 
context of the plug-in...." Therefore, associated metadata 160 comprises conditions 
required for successful execution of the functional module. Examiner provides no 
analog to metadata 160 in Win. In fact, Applicants submit that such analog does not 
exist in Win because Win only discloses determining access rights of users to system 
resources based on user roles. 

Therefore, Applicants submit that Win does not disclose assigning metadata 
requirements to functional modules, wherein the assigned metadata requirements 
specify conditions required for successful execution of the functional module. 

For the same reasons stated above, regarding claim 27 and the dependents 
therefrom. Win does not disclose a plurality of functional modules, each having 
associated metadata requirements that specify conditions required for successful 
execution of the functional modules. 

Tliere is no Reason or Suggestion to Combine Win and Pazandak. 

Examiner combines Win with Pazandal< in the rejection because Win does not 
disclose collecting runtime metadata relating to the query session, wherein the 
metadata is collected after the composition of a query. Win is related to a system for 
limiting user access to authorized resources based on the user's role in an organization 
that controls the resources. See Win, Abstract. However, Pazandak is related to a 
natural language interface that allow a user to input commands or inputs in natural 
language, to which devices and applications respond. See Pazandak, Column 1: Lines 
6-13. 
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Examiner provides no reason or suggestion to combine Win and Pazandak in tlie 
rejection. As argued in the appeal brief, on one hand, Examiner analogizes "runtime 
metadata" to "End-User selection from the menu choices" in Pazandak, and on the 
other, analogizes "runtime metadata" to "user roles" in Win. This variance in the 
definition applied to "runtime metadata" between the two references shows that the 
references are incompatible and that there is no reason or suggestion to combine the 
references. Further, as argued in the Appeal Brief, were the two references combined, 
the "collected runtime metadata" could not be both "user roles" and "End-User selection 
from the menu choices." 

Moreover, if the "collected runtime metadata" comprised "user roles," then the 
combination of the references would fail to teach collecting runtime metadata relating to 
a query session, wherein tlie metadata is collected after tlie composition of a query . If 
the "collected runtime metadata" included "End-User selection from the menu choices," 
then the combinations of the references would fail to teach identifying a limited subset of 
the functional modules in the list that will successfully execute, bv comparing the 
collected runtime metadata with the assigned metadata requirements . Accordingly, 
even if it were possible to successfully combine the two references, the proposed 
combination would fail to teach or suggest all of the claim limitations. 

For the reasons stated herein and in the Appeal Brief, Applicants submit that 
claims 10, 20, 27, and the dependents therefrom are allowable and allowance of the 
claims is respectfully requested. 
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CONCLUSION 

The Examiner errs in finding tliat claims 10-12, 14-21 and 27-29 are 
unpatentable over Win in view of Pazandak under 35 U.S.C. § 103(a). 



Withdrawal of the rejections and allowance of all claims is respectfully requested. 



Respectfully submitted, and 
S-signed pursuant to 37 CFR 1.4, 

/Gero G. McClellan, Reg. No. 44,227/ 



Gero G. McClellan 
Registration No. 44,227 
Patterson & Sheridan, L.L.P. 
3040 Post Oak Blvd. Suite 1500 
Houston, TX 77056 
Telephone: (713)623-4844 
Facsimile: (713)623-4846 
Attorney for Appellant(s) 
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